GFP is a new data link framing protocol, aimed primarily at block coding based on bit-synchronized transmission channels or packet-oriented data streams. GFP can allow flexible frame encapsulation to support fixed length data or variable length data, by implementing full encapsulation of variable-length user Protocol Data Units (PDU) and avoiding data splitting, data reforming and frame padding. This can simplify system operation and can improve processing speed and stability of a system. Unlike HDLC, however, which determines a frame boundary by padding the header with special characters, GFP uses a self-description technique based on Head Error Check (HEC), which delineates the frame boundary by 2-byte Payload Length and 2-byte HEC. As a result, GFP can overcome various shortcomings resulting from frame synchronization based on frame identification, thereby improving processing speeds and meeting the high-speed requirements of the next generation SDH.
As shown in FIG. 1, the structure of a GFP frame can include a Core Header, a Payload Header, Client Payload Information and a FCS. The Payload Header can further include four fields, namely, Payload Type (Type), Payload Type Error Check (tHEC), GFP Extension Header and Extension Header Error Check (eHEC).
The Type occupies 2 bytes, which indicate the content and format of the GFP payload information and includes a Payload Type Identification (PTI), a Payload FCS Identification (PFI), an Extension Header Identification (EXI) and a User Payload Identification (UPI). The PTI occupies 3 bits, which indicate the content type of the frame. The PFI occupies 1 bit, which indicates whether the frame carries the FCS at the end of the frame, wherein 1b denotes that FCS is carried, and 0b denotes that no FCS is carried. The EXI occupies 4 bits, which indicates the type of the extension header. The UPI occupies 8 bits, which indicates the data type of the user payload.
In communication networks, communicating partners need to exchange information. When a GFP encapsulation protocol is used, the transmitting side adopts the GFP protocol to implement full encapsulation of the payload while the receiving side needs to restore the client payload information, i.e., the receiving side needs to remove the fields other than the client payload information. However, because the FCS field is optional, some GFP frames carry the FCS field and some GFP frames do not carry a FCS field. Thus, the receiving side needs to identify whether there is an FCS field in the received GFP frame, and then remove other fields to obtain the payload correctly. At present, when the client payload information is being restored, many devices do not support the self-recognition function of the FCS field, but only support a certain fixed structure. For example, many devices only support the structure with an FCS field or the structure with no FCS field. This approach of receiving frames with a fixed structure cannot handle the circumstance when the transmitting side alternately or irregularly transmits GFP frames with FCS fields or without FCS field. This can result in inflexibility.
At present, FCS self-recognition can be implemented as well in an approach which involves both software and hardware. In this approach, before the transmitting side transmits a frame, the information in the Type field should be recorded by the software. When the receiving side receives the frame and identifies information in the Type field by the hardware, the receiving side transmits a corresponding alarm to the software to report the identified information. The software re-compares the received alarm information and the recorded Type-field information. If they do not match, then the software reconfigures the frame; otherwise, the software judges whether the frame includes an FCS field based on the recorded information. If yes, the FCS field is removed from the frame, but otherwise, the software does nothing. As the software configuration is adopted, error codes are inevitably produced using this approach and the processing speed thereof is slow. Moreover, when frames with FCS fields and frames with no FCS fields are transmitted alternately, the software must switch frequently, making the self-recognition process nearly impossible and correct separation of the payload unachievable. This again can result in little flexibility.